The present invention generally relates to optimizing service deployment in a distributed computing environment and, more particularly, to optimizing service deployment in a distributed computing environment by reducing internal application programming interface (API) calls by individual application instances.
A distributed computing-based application (e.g., a cloud-based application) may interact with other micro-services and persistence storage devices to construct its in-memory state. Such interaction may include conducting multiple API calls on external service provider servers to obtain data which is then used to make internal API calls to construct the in-memory state of the cloud application.
As an illustrative example, suppose a cloud application receives a request to deploy a new artifact (e.g., a connector artifact) in connection with implementing a service (e.g., a connector service). As part of processing and executing the deployment, the cloud application may need to make a series of API calls on different external service provider and storages devices to obtain data regarding the configuration for the new connector artifact. Subsequently, the cloud application may need to make additional API calls on an external application server running a Software as a Service (SaaS) application corresponding to the connector type to obtain additional metadata about the connector to be created. The cloud application may then use all the data collected from the various sources to make internal API calls to create the connector in-memory. At this point, consumers of the connector service may utilize the newly deployed connector.
The above process may need to be repeated for each instance of the application cluster so that connector service requests can be load-balanced to a number of identical instances. For every connector artifact deployed, the external API calls are made by each instance. Also, in a case when an application cluster crashes, the above process must be re-executed in order for each instance to recreate its in-memory state prior to the crash and all the API calls would again need to be conducted as described above.